Overall, FDW parallel scan is a direction worth exploring, but this approach is too rough. The core problems are:

1. locus transition semantics for Gather in an MPP context haven't been thought through, and the changes are too broad.
2. FDW is a black box from the database's perspective.
   For heap tables we have parallel scan (divide work by pages), for AO/AOCS we have parallel scan (divide work by files) — the work partitioning is well-defined.
   But for FDWs, the parallel behavior depends entirely on the FDW's own implementation. If an FDW (say file_fdw) sets parallel_safe = true following planner's parallel logic but doesn't actually implement the DSM parallel callbacks (EstimateDSMForeignScan, InitializeDSMForeignScan, InitializeWorkerForeignScan), then multiple workers will each scan the full dataset, producing duplicate rows.

I'm not very familiar with Cloudberry. Still learning.

FDW itself is a black box. Its specific implementation largely depends on how the user implements it. My understanding is that users need to take responsibility for their own implementations. Additionally, I should only enable gather for FDW. In other cases, it should remain false, this will parallel processing advantages of PostgreSQL?

Additionally, I've looked into other aspects of FDW parallelism. Currently, it seems there is no optimal solution.

So, should we aim to implement parallelism that is transparent to users? Or are there better approaches? Could you share some idea?

Overall, FDW parallel scan is a direction worth exploring, but this approach is too rough. The core problems are:

1. locus transition semantics for Gather in an MPP context haven't been thought through, and the changes are too broad.
2. FDW is a black box from the database's perspective.
   For heap tables we have parallel scan (divide work by pages), for AO/AOCS we have parallel scan (divide work by files) — the work partitioning is well-defined.
   But for FDWs, the parallel behavior depends entirely on the FDW's own implementation. If an FDW (say file_fdw) sets parallel_safe = true following planner's parallel logic but doesn't actually implement the DSM parallel callbacks (EstimateDSMForeignScan, InitializeDSMForeignScan, InitializeWorkerForeignScan), then multiple workers will each scan the full dataset, producing duplicate rows.

I'm not very familiar with Cloudberry. Still learning.

FDW itself is a black box. Its specific implementation largely depends on how the user implements it. My understanding is that users need to take responsibility for their own implementations. Additionally, I should only enable gather for FDW. In other cases, it should remain false, this will parallel processing advantages of PostgreSQL?

Additionally, I've looked into other aspects of FDW parallelism. Currently, it seems there is no optimal solution.

So, should we aim to implement parallelism that is transparent to users? Or are there better approaches? Could you share some idea?

Neither PostgreSQL nor Cloudberry supports parallel FDW scans, that's a deliberate decision, not an oversight.

On the implementation side: having the kernel generate partial paths for FDW will cause FDWs that don't implement parallel scan callbacks to silently produce wrong results (e.g. duplicate rows). That's a kernel bug, not a user error — we can't shift that responsibility to FDW authors. And mixing Gather with CBDB-style parallelism remains fundamentally broken — the locus handling is wrong, and none of the issues I raised (joins, locus transitions, the overly broad execMain.c change) have been addressed.

More importantly, before discussing how, we need to answer why. What real-world problem does this solve in an MPP system where FDW is already used across segments? And given the risks I mentioned above — broken locus transitions, silent wrong results for existing FDWs, untested join/subquery interactions — even if it can be done, is it worth the complexity? If you want to push this forward, you need to make the case clearly: what's the motivation, and convince us that all the issues raised have sound solutions.

Overall, FDW parallel scan is a direction worth exploring, but this approach is too rough. The core problems are:

1. locus transition semantics for Gather in an MPP context haven't been thought through, and the changes are too broad.
2. FDW is a black box from the database's perspective.
   For heap tables we have parallel scan (divide work by pages), for AO/AOCS we have parallel scan (divide work by files) — the work partitioning is well-defined.
   But for FDWs, the parallel behavior depends entirely on the FDW's own implementation. If an FDW (say file_fdw) sets parallel_safe = true following planner's parallel logic but doesn't actually implement the DSM parallel callbacks (EstimateDSMForeignScan, InitializeDSMForeignScan, InitializeWorkerForeignScan), then multiple workers will each scan the full dataset, producing duplicate rows.

I'm not very familiar with Cloudberry. Still learning.
FDW itself is a black box. Its specific implementation largely depends on how the user implements it. My understanding is that users need to take responsibility for their own implementations. Additionally, I should only enable gather for FDW. In other cases, it should remain false, this will parallel processing advantages of PostgreSQL?
Additionally, I've looked into other aspects of FDW parallelism. Currently, it seems there is no optimal solution.
So, should we aim to implement parallelism that is transparent to users? Or are there better approaches? Could you share some idea?

Neither PostgreSQL nor Cloudberry supports parallel FDW scans, that's a deliberate decision, not an oversight.

On the implementation side: having the kernel generate partial paths for FDW will cause FDWs that don't implement parallel scan callbacks to silently produce wrong results (e.g. duplicate rows). That's a kernel bug, not a user error — we can't shift that responsibility to FDW authors. And mixing Gather with CBDB-style parallelism remains fundamentally broken — the locus handling is wrong, and none of the issues I raised (joins, locus transitions, the overly broad execMain.c change) have been addressed.

More importantly, before discussing how, we need to answer why. What real-world problem does this solve in an MPP system where FDW is already used across segments? And given the risks I mentioned above — broken locus transitions, silent wrong results for existing FDWs, untested join/subquery interactions — even if it can be done, is it worth the complexity? If you want to push this forward, you need to make the case clearly: what's the motivation, and convince us that all the issues raised have sound solutions.

Parallel FDW primarily addresses the issue of slow data loading. This functionality was already implemented in earlier versions of PostgreSQL. Now, I am attempting to integrate this feature into MPP systems. In simple tests, parallelization has indeed delivered a performance improvement of one to two times. Such gains are essential for performance-sensitive business scenarios. Therefore, I am working to introduce this functionality. Alternatively, we could discuss the implementation plan in the issue tracker.

Thank you for the detailed review comments. Regarding the core issues raised (the security impact of partial paths on FDWs that do not support parallel callbacks, the mixing of Gather and CBDB gang models, locus conversion, and the scope of changes in execMain.c), I agree that these are all issues that need to be addressed seriously.

After reconsideration, I am inclined to withdraw the kernel-side modifications and adopt a pure FDW-layer solution instead. The core idea is:

1. Do not modify the kernel's partial path generation, execMain.c, or locus logic—avoiding all the risks mentioned above.
2. The FDW directly uses CBDB's existing parallel variables (ParallelWorkerNumberOfSlice / TotalParallelWorkerNumberOfSlice) to obtain the current worker number and total count.
3. During execution, the FDW calculates the virtual segment ID based on these two values, modifies the HTTP header sent to PXF, and allows PXF's round-robin sharding mechanism to automatically distribute data evenly among all gang workers.

This solution requires no kernel modifications and will not affect other FDWs.

I would like to confirm: Is this direction reasonable? Are the variables ParallelWorkerNumberOfSlice and TotalParallelWorkerNumberOfSlice stable and reliable under the current CBDB parallel framework? Or do you have a more recommended way for the FDW to perceive gang parallel information?

Among the existing parallel frameworks in CBDB, after FDW registers a partial path via add_partial_path(), can the planner correctly trigger gang expansion and set ParallelWorkerNumberOfSlice? Or does it require additional kernel adaptation?

Parallel FDW primarily addresses the issue of slow data loading. This functionality was already implemented in earlier versions of PostgreSQL.

Where exactly? Are you referring to this commit?

This solution requires no kernel modifications and will not affect other FDWs.

I would like to confirm: Is this direction reasonable?

That sounds more reasonable.

Are the variables ParallelWorkerNumberOfSlice and TotalParallelWorkerNumberOfSlice stable and reliable under the current CBDB parallel framework?

Yes, they are stable and reliable under the current CBDB parallel framework. But I'm not sure how you plan to use them.

During execution, the FDW calculates the virtual segment ID based on these two values, modifies the HTTP header sent to PXF, and allows PXF's round-robin sharding mechanism to automatically distribute data evenly among all gang workers.

I'm not entirely sure I follow — isn't this essentially how MPP PXF works today? except the virtual segment ID based on these two values -- not sure, off the hand I think it's not enough, different Slice on same Segment could have same parallel workers.

Are the variables ParallelWorkerNumberOfSlice and TotalParallelWorkerNumberOfSlice stable and reliable under the current CBDB parallel framework?

Yes, they are stable and reliable under the current CBDB parallel framework. But I'm not sure how you plan to use them.

During execution, the FDW calculates the virtual segment ID based on these two values, modifies the HTTP header sent to PXF, and allows PXF's round-robin sharding mechanism to automatically distribute data evenly among all gang workers.

I'm not entirely sure I follow — isn't this essentially how MPP PXF works today? except the virtual segment ID based on these two values -- not sure, off the hand I think it's not enough, different Slice on same Segment could have same parallel workers.

Yes, essentially, it reuses the existing MPP round-robin sharding mechanism of PXF—by modifying the segment ID/count in the HTTP header, PXF can distribute data to N×W gang workers instead of N physical segments. No changes are required on the PXF server side.

Regarding ParallelWorkerNumberOfSlice: From the assignment logic in parallel.c, workers on the same segment are assigned incrementally via DSM entry (0, 1, 2, ...), which should be unique. However, I want to confirm: In the CBDB parallel framework, is this value guaranteed to be unique within the same slice on the same segment?